home *** CD-ROM | disk | FTP | other *** search
/ BBS Toolkit / BBS Toolkit.iso / remote / pr_ra111.zip / PROTO_RA.TXT < prev    next >
Text File  |  1991-11-13  |  15KB  |  339 lines

  1.  
  2.                 P r o t o _ R A   1 . 1 1
  3.  
  4. Wed  11-13-1991  18:41:52
  5.  
  6. NOTE:
  7. Minor changes from 1.10, plus a corrupted PROTOCOL.GSZ, made
  8. this release necessary.  More NEW things later, I hope!
  9.  
  10. This is a compendium on the use of external protocols with
  11. RemoteAccess.  With this are sample PROTOCOL.RA that must
  12. be modified for use with your system.  One using DSZ.COM is
  13. named PROTOCOL.DSZ and another using GSZ.EXE is named
  14. PROTOCOL.GSZ.  Rename the one which you want to use to
  15. PROTOCOL.RA before modifying it for your system.  All
  16. protocols must be set up first according to their own
  17. documentation.  Any special notes are included below, but
  18. the basic thing to remember is that you MUST set up the
  19. protocol to write a log file, and it must (of course) be the
  20. same name as the log file used in PROTOCOL.RA.
  21.  
  22. The PROTOCOL.RA samples assume you are running single node,
  23. with all protocols in the system directory.  They require a
  24. complete path if elsewhere, or (of course) if you run
  25. multinode.  With a few changes in commands, all will have
  26. enough space to fit the path in, with the exception of
  27. SZModem.  Since it MUST have the /CFGPATH parameter with
  28. version 1.50, and /DORINFO 1 in version 1.60, there is not
  29. enough room for any path, except for c:\ with 1.60 <grin> .
  30.  
  31. Note that these are set for locked bps (mine is at 38400),
  32. and must be edited for other systems.  TEST ALL PROTOCOLS;
  33. what works on one system may not work on another, and vice
  34. versa!
  35.  
  36. I have also included a sample .cfg file for FileDoor 2.03.
  37.  
  38. 1) Protocols that work with BPS locked at 38400:
  39.  
  40.  A) DSZ, GSZ
  41.  
  42. These work in all modes, except (in RA 1.01) for single file
  43. protocol modes (Xmodem and derivatives) for uploads.  This
  44. problem is due to RA passing only the path as # on the
  45. command line, and is fixed in RA 1.10.
  46.  
  47. The only difference between DSZ and GSZ is the name of the
  48. executable (DSZ.COM or DSZ.EXE versus GSZ.EXE) and that for
  49. display speed you may want to add pV1 just before the
  50. protocol command (e.g., pV1 sz).  GSZ.EXE and DSZ.COM
  51. support file sharing; DSZ.EXE does not.  DSZ.EXE and GSZ.EXE
  52. support up to a 16k pB buffer command, while DSZ.COM is
  53. limited to 4k.  My recommendation is to use the default
  54. unless, as Chuck Forsberg says, you are bloody well sure you
  55. need the pB command!
  56.  
  57. They will also only work for uploads if you have them
  58. registered, as the unregistered versions will not accept a
  59. received file into a pathed directory.  See PCZ and ZSX
  60. below for alternatives if you do not have a registered copy
  61. of DSZ and/or GSZ.
  62.  
  63. You must set DSZLOG in your environment as well, and use the
  64. log for PROTOCOL.RA.
  65.  
  66. Some special modes are not practical, but will work.  These
  67. are the modes that DSZ uses only to recieve.  Among these
  68. are ro (Overthruster), rx -g (Xmodem-k-g) and rb -g
  69. (Ymodem-g).  This also includes rc (Xmodem CRC/Xmodem-k
  70. CRC), but rx will also receive CRC.  Now, the thing to do is
  71. use the more generic form to send, and assume the receiver
  72. knows he must use the proper form to get the protocol
  73. desired.  For ro, use sx; for rx -g use sx -k; for rb -g,
  74. use sb -k.  An example for Xmodem Overthruster, with the
  75. proper windowing for packet-switched networks, is included.
  76.  
  77. Another oddball is Zmodem compressed, as it is set on the
  78. SENDING side with sz -Z.  Use the standard rz to receive.
  79.  
  80.  B) MPt (formerly Puma)
  81.  
  82. Works just fine, but you must set the DSZ-type log in
  83. MPTSET.  I suggest using MPT.LOG myself, to separate it
  84. from DSZ.  No real other comments!
  85.  
  86.  C) TASY
  87.  
  88. You must set TLOG in your environment, and use version 4.19
  89. of TASY.  This is a error correcting connection protocol
  90. only, and should be so set.  Later versions do not seem to
  91. work right, and earlier ones had no log.  Seems very fast!
  92.  
  93.  D) SZModem
  94.  
  95. READ THE DOCS and set this one up only after you have them
  96. mastered!  It will use whatever you have set for DSZLOG in
  97. the environment, and the /CFGPATH must point to where the
  98. szmodem.cfg resides.  1.42 and up are the best to use, as
  99. they work more as they should in regards to the /cfgpath and
  100. DSZ environmental variables.  SZModem as of version 1.50
  101. still uses only uppercase Z to indicate transfers in either
  102. direction, rather than the correct z for send and Z for
  103. receive.
  104.  
  105. Occasional modems or conditions will result in status
  106. Unknown transfers, which return no transfer.  Perhaps the
  107. author will reverse this and assume success rather than
  108. failure on such transfers in the future, as for the most
  109. part they ARE successful, and users will be able to leech a
  110. file or two as is once in a while <grin>.
  111.  
  112. SZModem 1.60, just released, fixes the DSZ.LOG problem.  It
  113. also stores all config data in the executable.  The
  114. dorinfo1.def processing, though, has to be specified on the
  115. commandline, though the path is set in the configuration.
  116. For multinode, this may well allow such use, as the default
  117. dir will be the place SZModem will look for the dorinfo1.def
  118. file.  The examples given in the sample PROTOCOL.?SZ files
  119. use this new version; for other version's commandlines, see
  120. the FileDoor.Cfg (though you will have to eliminate the
  121. /FIDOAREA for lack of room).
  122.  
  123.  E) SKHST
  124.  
  125. Though SuperK will also work, this is easier to set up and
  126. has new features to make it work a LOT better as a BBS
  127. protocol.  If you do not register, it will die after 30
  128. days.  DO REGISTER it, but if you need more time, you can
  129. reinstall after deleting a hidden file in the root dir of
  130. your hard disk that it creates (name looks like ascii
  131. garbage).
  132.  
  133. The single modes will not work for ULs in RA 1.01 for the
  134. same reason as some DSZ modes, the # character not passing
  135. the path AND filename to the protocol.  Fixed in RA 1.10.
  136.  
  137. With version 1.06, SKHST will try on the receiving end to
  138. match the batch mode send of the remote.  This means if they
  139. make a mistake and use the wrong mode, it will still receive
  140. the file.  Since it cannot match the other way, you still
  141. need the sending modes you want to support.  I recommend the
  142. modes I have in PROTOCOL.RA as they support the ProComm
  143. brain-dead WXModem (whoever heard of a window of 1 block?),
  144. and the old SuperK batch modes.
  145.  
  146. YOU MUST set up SKHST to NOT delete its transfer file!  The
  147. default is to delete it, and since RA tries to delete it as
  148. well, this does not work well!  If you have SHARE loaded,
  149. you will get a violation and a crash.  Also be sure to set
  150. the full path of the log and xfer files in the protocol
  151. setup and in PROTOCOL.RA.  The xfer list file can be
  152. XFER.TXT with the path, or some other; the commandline
  153. overrides the protocol's set xfer list name.  I use
  154. XFER.TXT, myself.
  155.  
  156. By the way, the Jmodem mode of SKHST does not work for me,
  157. for whatever reason, neither in FileDoor nor in RA's
  158. externals.  If it did, it could replace the "real" Jmodem
  159. that does not write a log and thus cannot be used at
  160. present.
  161.  
  162.  F) PCZ
  163.  
  164. The freeware PCZ works well, with some limitations.  The
  165. zmodem mode will accept a DL path, unlike unregistered DSZ.
  166. There is no Ymodem-g or Xmodem-k-g mode, but it does include
  167. an implementation of SEAlink in addition to xmodem,
  168. xmodem-1k, and ymodem.
  169.  
  170. Do not use the DIRXX setting, at least not with the 4.09.90
  171. version of PCZ.  The commandline does not reliably override
  172. the set command.  Do use the Set PCZLOG variable, and use
  173. normal DOS methods (e.g., set pczlog=c:\ra\pcz.log).  Locked
  174. at 38400, the internal flow control seems to break down with
  175. the lower speeds, so the F (fossil) setting is needed.  You
  176. should then, if the fossil is locked, pass the DCE as *b to
  177. the protocol so the time calculations are correct.  You may
  178. wish to advise your users of this as well, and tell them to
  179. load BNU and lock the port, run PCZ, and unload BNU, if they
  180. run at 38400.
  181.  
  182. The only other problem is that the logging PCZ does is
  183. ambiguous to RA's scanning method.  If an aborted transfer
  184. takes place with exactly 1 error, RA will find the 1 for the
  185. logged error, assume the xfer went ok, report it as
  186. complete, and then find the day of the week as the filename.
  187. No harm done, but rather confusing to the user.  The author
  188. is being made aware of this, and either it will be fixed or
  189. perhaps RA can scan for a string including spaces (1  sz for
  190. a zmodem send, for example) in a future version to make it
  191. unambiguous.
  192.  
  193. One other note concerns PCZ's errorlevel generation, not
  194. directly of concern for PROTOCOL.RA use.  The zmodem and
  195. ymodem (not sure about xmodem and xmodem-1k) work correctly,
  196. but the SEAlink seems to always return an errorlevel of 1
  197. (failure).  This has to do with its correctly sending the
  198. EOF, but not the EOT, I believe, or not responding correctly
  199. to the receiving end.  The SEAlink implemention also does
  200. not include SLO (SEAlink Overdrive) and is not very reliable
  201. at 9600 DCE rates.  However, it is MORE reliable than ZSX at
  202. 2400 and below, especially with a non-error correcting
  203. connection.  I have used it therefore for SEAlink.  I have
  204. also used it for Super_Z, a variant similar to DSZ's
  205. MobyTurbo, a faster zmodem than usual CRC32 is.
  206.  
  207.  G) ZSX
  208.  
  209. ZSX includes xmodem, xmodem-1k, ymodem, ymodem-g, zmodem,
  210. SEAlink, and SLO (SEAlink Overdrive).  It is not crippled in
  211. any way, and uses the fossil for all communications.  It
  212. uses the DSZLOG environmental variable.  All modes use the
  213. lowercase protocol letter to log success (that is, s for
  214. SEAlink and SLO, z for zmodem, g for ymodem-g, etc.).  The
  215. limitations I have found to date are that it will not accept
  216. the new v.32bis rates as the speed parameter (since it uses
  217. the locked fossil, there is really no reason this must be
  218. this way, and perhaps will be changed in the future) and it
  219. sometimes sends some characters to the remote after a
  220. tranfer is complete, so the user may find themselves not
  221. where they thought once in a while ;-)
  222.  
  223. For whatever reason, it does NOT seem to work well at lower
  224. speeds without error correction in SEAlink mode, at least
  225. not when locked at 38400 bps.  The SLO mode, on the other
  226. hand, works ok, except at 2400/ARQ on uploads.  Thus, I have
  227. used it for SLO, but disabled it in the samples.  It *may*
  228. work just fine on another system, though!
  229.  
  230. The other modes do not seem to share the SEAlink problems,
  231. although my testing has been somewhat limited.  Have fun!
  232.  
  233. Registration is a postcard to the author.  If you cannot
  234. register DSZ, this is a viable alternative as well!
  235.  
  236.  H) Hyperprotocol
  237.  
  238. An odd log file is created by Hyperprotocol, but it can be
  239. read by RA in most cases.  The actual outcome is in TWO
  240. "words", the first and last, so aborts may not always be
  241. recognized by RA.  The bigger problem is that it can only be
  242. used to upload to a specific directory, as RA replaces #
  243. with the upload directory WITH a trailing backslash, and
  244. this confuses Hyperp, which will lock up the machine at
  245. times.  IF you only use a single upload directory, this will
  246. work fine; otherwise, wait until Hilgraeve fixes it!  The
  247. latest I know about, 1.1f, has this problem.  You must have
  248. an option file like HYP.OPT for it to work, in the same dir
  249. as the hyper.exe:
  250.  
  251. DISPLAY:OFF
  252. HANDSHAKE:RTS/CTS
  253. LOGFILE:C:\RA\HYP.LOG
  254.  
  255.  
  256. 2) Random notes on a lot of other protocols:
  257.  
  258. Protocols that do not write a log will not work.  Perhaps
  259. this can be added to RA at some time, to use errorlevel 0
  260. for success and 1 for failure in lieu of a log file.  Some
  261. good ones are in this group, including Jmodem.  Translink
  262. and HyperDrive would appear also to work if I can find
  263. versions with bugs fixed (the former limits the path an
  264. filename to about 16 characters, the latter I cannot find a
  265. whole copy!).  These all work with 38400 locking as well.
  266.  
  267. Tmodem, the X, Y, Z, and Zmax cousins of Tmodem, and Zyrion
  268. all are to avoided, in my opinion.  They will work at 38400
  269. locked, and do write log files.  However, (except Zyrion)
  270. they all ask for an odd -b parameter.  This seems to be the
  271. DCE rather than the DTE, which must be set in the
  272. environment with a set COMx= command.  With v.32bis CONNECT
  273. codes, this breaks down.  They seem to demand 9600 as the
  274. "baud" rate, which is neither the DTE of 38400 nor the DCE
  275. of 14400.  Appeals for explanation and help have netted
  276. nothing, and I am a registered Tmodem user.  In addition,
  277. Tmodem has several incompatible versions (under 2.0,
  278. 2.0-3.x, 5.0-6.3, 6.4, and now 7.0, NONE of which work with
  279. any others outside their own group), and now that is
  280. extended to the X, Y, Z, and Zmax versions as well.  In
  281. versions under 7.0, the log is written in the default
  282. directory only, which could present problems.  The basic
  283. support does not exist unless registered, and if you
  284. register, the support consists of telling you it works fine
  285. with Isis/Osiris (being as nice as I can be here!).
  286.  
  287. rC-Modem does not work at 38400, or any locked BPS, as far
  288. as I can tell.  NModem does not either, but I am not too
  289. sure if it works at all.  I have been unable to get it to
  290. work, in any case.
  291.  
  292. PC-Kermit barely works as 19200, dies at 38400, and does not
  293. write a log.  Megalink works at 19200, not at 38400, and
  294. also does not write a log.  Clink works fine at 38400, but
  295. does not write a log, and will not accept a path to receive
  296. a file, making it useless even if errorlevel support is
  297. added someday.  It does work with FileDoor, though, if you
  298. do not have philosophical objections to running it at all!
  299.  
  300. Punter does not work locked, not write a log.  Quicktran is
  301. the same, and is terribly slow with archived files anyway.
  302.  
  303. The old Friel Imodem is not even supported by Qmodem any
  304. more, so I suggest you do the same!  Odds are it does not
  305. work locked at 38400, and I know it does not write a log
  306. file.  It also is slower for error correcting transfers than
  307. other g protocols.
  308.  
  309. MSKermit is an OK terminal package, but a horror to use as
  310. an external protocol.  It likes to claim the comm ports as
  311. its own, a bad thing when running under a BBS!
  312.  
  313. I have not tried all the Opus specific protocols, but see
  314. little there to get excited about.  For the sake of
  315. completeness, I will do it someday.  I have tested oKermit
  316. 1.04, which would not work for me at all, though Peter
  317. Janssen runs it.
  318.  
  319. While not an exhaustive list of protocols, I think this
  320. reflects most of those available today.  I think the
  321. internal RA external protocol support could easily work with
  322. all reliable protocols with the addition, some day, of
  323. errorlevel support to the logfile support it has now.
  324.  
  325. I hope this is of use to someone!  Comments, additions, and
  326. all are welcome.  Hopefully this can be the beginning of an
  327. ongoing project to provide protocol installation information
  328. for RA.
  329.  
  330. The files herein contained are only guaranteed to occupy
  331. diskspace, and blah blah (usual disclaimer).
  332.  
  333. Bob R.
  334. 1:154/40@fidonet.org
  335. The Anonymous BBS
  336. Fussville, WI
  337. 414-251-2580
  338.  
  339.